It's been over 4 years since we planned the infamous GUI update. If all goes well, next week the game will get the last big GUI update for 1.0. While the state of the GUI is not close to our crazy plans we recently had for the GUI, it's above what we initially planned 4 years ago. The update you will see next week includes: A visual update to over 100 game GUIs New high resolution icons for all game items (visible both in GUI and in the world) New GUI sounds for most interactions

New hope demo levels Klonan A few weeks ago we discussed the changes to the demo and tutorial in the game (FFF-342). One piece of feedback we received after publishing the news was about the old 'New hope' campaign levels, and specifically the 'Abandoned rail base/Broken rail map'. It seems a lot of you in the community really really enjoyed the new hope campaign levels, and several of the team here share the same feelings. After we scrapped the plans for a new campaign and reverted to the old demo, we had initially dismissed the idea to revive the New hope campaign... However due to popular demand... we have decided to bring back the favourites, the first 2 levels of the new hope campaign. This time though, they will also be included in the demo version of the game. This represents a very significant increase in scope for the demo, increasing the demo content to include research, red science, green science, trains, and much more. These levels should be ready for release within a week (but no promises).

He who does nothing, breaks nothing posila In the recent patch notes, there was a line "Fixed landfill spawning under player when building landfill elsewhere. More" and some people on Reddit were wondering how did this bug happen in the first place, and asked for the long version and even suggested we could even use it for Friday Facts, and I thought: "Yeah, if I am going to spend time writing this, we should consider using it in FFF so someone else doesn't have to spend time writing something else." ... but I am going to stretch it out. The landfill bug reported after the release of 0.18.21. Disclaimer: I have not been around during the ancient parts of this story (speaking of which, it's my 5 year anniversary at Wube, yay!), and changes I have been around for, or even done myself, I might not remember correctly. So this might not be accurate. In fact, let's say the story is purely fictional and any resemblance to real world events and people is just a coincidence.

Unit group collision mask Last weekend, a bug report came in on our forum. The issue was that the groups of biters were trying to path over the water, but the bugs can't swim. It seemed like something quite typical of a mod being funky. I looked into it, and it seems the Hovercraft mod was playing monkey business with water collision masks to make his vehicles ride over water. One thing involved setting water tiles to be walkable, and then adding an additional collision layer to all players and biters. What this modder didn't realise though, is that unit groups have a fixed collision mask. It used to be hardcoded, but a while ago it was added to the utility constants. So we just say "hey its a mod problem, here's a quarter, call someone who cares"... right? Well it didn't sit right with me, because deep inside I knew that the unit groups shouldn't have a fixed collision mask, it doesn't make sense really. Lets say you add flying units to the game. If you give individual commands to the flyers to go attack the base, they will happily fly over the water and attack without issue. However if you put them in a group together, a group of flying units, the group will path around the water, because the unit group still has a fixed ground collision mask. So this week I decided to fix it once and for all. It turns out it wasn't so hard in the end. As we mentioned somewhat in FFF-340, unit groups already have logic in place to recalculate their properties based on their members. I hooked into that logic to also make them recalculate their collision mask. The way that made sense to me, is that they should add the masks together, so that they only path where all of the units can path. A group of only small biters, they can't walk on water, so they walk around it. A group of 'water biters'. They can walk right over water, so they go straight through. A mixed group of small biters and water biters. They add their masks together, so only go where all the units can go. You can imagine it quite intuitively I think, the group will try to stick together, and that will mean the group can only path to places that all the members can reach. It feels quite nice to make fixes like this, as they are relatively small in scope and risk, but cleanup a lot of potential problems, and open a lot of interesting possibilities.

Tile transition collisions Klonan We first mentioned a change to our tile transition logic back in FFF-199, and not long after in FFF-214. These two posts focused more on the visual side, and how it makes the game terrain look so much better. In short, the tile transition logic overlays an additional sprite over adjacent tiles, so that where the two tiles meet has a much more natural look. Left: Tile transitions on; Right: Tile transitions off. So while the looks were taken care of, we also had to deal with the 'feel' of the tiles. The easiest example of this is the 1x1 landfill 'stepping stones'. It really looks like you should be able to walk/drive across the 1 tile of water. So we added in an additional layer of collision checks, which will consider the transitions when performing the logic of what can go where. Now some of the cheesier among you will know that biters don't know how to get across these 1 tile gaps. That is because simply we never enabled the biters to use this collision check logic. One reason is that more checks means more UPS usage for the biter pathfinding, another is that we didn't think it was necessary. However it was available in the engine, and any mod could enable it if they want. That is exactly what I did with my Mining drones mod. Initially this seemed to work, and I thought it might make them walk around lakes a bit more naturally (like the player character does). However quickly I noticed that people were reporting on the forum that the game was crashing with the mod installed. I quickly reverted the change to my mod and we started looking into it. It turns out that the new abstract pathfinder we added for better unit pathfinding (FFF-317) was not set up to consider units using this tile transition collision logic. This same crash was happening sometimes without any mods installed, but the case was more difficult to reproduce, so this is a nice situation where mods help us work on issues in the base game. Recently I have been working on another unit heavy mod, Transport drones, and the principle design behind the mod heavily relies on the tile collision logic (the units don't even collide with entities). It turned out to be a really nice test of our new pathfinder, but also highlighted some of the issues that not considering the tile transitions can bring. By not considering the tile transitions, the drone takes an awkward path along the diagonal road. This week Oxyd finished his work on an upgrade to the pathfinder, so we can enable the tile transition collision logic with units. The change is immediately noticeable with the above example. By considering the tile transitions, the drones path much more naturally. With the logic now in place, we are debating whether to enable it for biters or not. We probably won't, it is only a minor change and would have a non-zero performance impact (a rough test puts the worst case at about 5%), but then again it is a fun way to surprise those who thought the 1 tile of water would stop the biters attacking, and it kinda makes sense they can walk over it just as the player can. Well we will see if there are any issues with it in the modded cases before any further consideration. As a bonus fact (this is Factorio facts after all), I spent a bit of time benchmarking some late game Transport drone based factories (screenshot), and found a few nice performance gains.

Environmental particle effects Dom Since the particle optimization we did for 0.18 (FFF-322) and the introduction of new explosions (FFF-325), we were able to push our vision even more. It always bothered me that the grenade and other explosions would emit the same type of particles regardless of the context. In most cases it isn't that bad, and somewhat okay, but when you throw a grenade into water, it will still emit stone particles, which breaks the illusion. Another problem is that we have the nice decoratives on the ground, but they don't really 'interact' with anything that goes on, and can feel like fake flat stickers instead of something 'real'. You would expect that when there is a massive explosion 2ft away, the bushes might have some reaction to that. The explosion effect currently in 0.18

Not mentioning it would be weird I really think everybody has heard all about this and nothing else over the last few weeks, but yes, the Coronavirus. For now, with Factorio, everything seems okay. We are all working from home, the team is still going, and so far we are following our plan quite well. We released the Character GUI and Statistics GUI last week, and some improvements such as new water splashes and leaf animations this week. Things are still moving along. However it is still early days, we haven't really had any experience having the whole team work remotely, so there may be some challenges we need to tackle as time goes on. At the moment we don't know whether this will affect our 1.0 release date, I guess it will one way or the other, but for now we aren't announcing any changes.

Statistics GUI Klonan, Oxyd The statistics GUI (electric network stats, production stats, etc.) is one of the GUIs that has been in the game for a very long time, and has had its functionality fleshed out reasonably over the years. It was not long ago when Twinsen added hovering and highlighting to the graphs. Given that, and the relatively short timeframe for 1.0 release, the update of the statistics GUI has really just been a style update, no new features or heavy logic rewriting. Oxyd has most of the work done, so we are happy to show some real in-game screenshots of how it looks: A notable change with the electric stats is that the Satisfaction/Production/Accumulator charge are next to each other in a single row, as opposed to each in a separate row. The label for the exact amount has also been moved to inside of the progress bar, which itself is much thicker. The production stats are pretty much the same functionality wise. One new button you might spot is the search button. However there are some problems with the search feature. As you can see, production and consumption frames have a different search box independent from each other. The main problem is when pressing CTRL+F to perform a regular search: How do we know which frame to open? Of course this could lead to different solutions like the use of a cycle for the focus of the search, in which the second time you press CTRL+F the other frame gets the focus. Or both of the search boxes open at the same time but only one gets the focus. Or only one frame gets the focus and the other one works only by pressing the button. But let's face it, these "solutions" are not solid at all and create inconsistency in the main design. To solve this issue we decided that the simplest way to go is the use of just one search box on the header of the panel. This new location works as a general feature for the entire panel. One single search gives you 2 results, one on each frame. This solution is used in the new character window -to come soon- making it consistent with the whole design of the GUI. You can also see we took this opportunity to integrate the Kill statistics in with the rest, instead of being its own window with its own hotkey. The Statistics GUIs will need a few tweaks and polishings here and there before it is ready for release, but unless something unexpected happens you can expect it coming out in a release soon.

Team production changes Improving the Team production challenge was prompted by this Reddit post. Team production was made back in 2016 to test the multiplayer networking of the 0.14 update with a larger number of players without the overhead of having a large factory. Since then it has not really had much love. So after 4 years of accruing wisdom, I started making some general improvements.

Poison cloud Ernestas, posila The poison cloud animation is a placeholder spritesheet (that kovarex found somewhere on the internet), we have wanted to improve it for a long time, but since it was always such a small detail other things took priority. Well now is the time to finish everything, big and small. Some of the problems we see with the old placeholder animation: The edge (where damage will apply) is not clearly defined The center strongly obstructs vision underneath the animation It breaks the perspective/height illusion with its very circular shape The new animation was done quickly and without the need of any large changes to the Factorio engine. This is the mindset we are in these days, use the engine features we already have to finish things quickly and without trouble, and we try to stop ourselves going crazy with more detail. The smoke capsule itself spawns a bunch of smaller dummy entities which do the smoke drawing, while the damage is kept consistent by only using the central smoke cloud to apply damage.